Day 20 ｜主動引爆未知缺陷：以濫用案例反向設計

2026 iThome 鐵人賽

DAY 21

Security

18th鐵人賽

23 瀏覽

Introduction

在傳統的功能性軟體品保測試（Functional QA Testing）中，團隊絕大部分的心力都花在「正向測試（Positive Testing）」——輸入規格書定義的標準資料，求神拜佛保佑它流程能跑通、功能會動、可以準時上線。

但在軟體資安測試（Security Testing）的領域裡，核心視角完全反轉：想盡各種辦法把系統搞殘的負向測試 (Negative testing)。

如果把開發軟體比喻成「經營一家外送餐廳」：

資安測試的本質，不是驗證系統「做了什麼該做的事」，而是證明系統「在面對惡劣環境或惡意攻擊時，絕對不會做出不該做的事」。

攻擊者能否在 1 毫秒內同時送出 5 次相同折價券請求？
攻擊者能否將折價券折扣金額修改為超過訂單總額，導致結帳金額為負？
攻擊者能否套用其他租戶專屬的企業折扣碼？

概念	The Core Question	Focus	Output
驗證 (Verification)	我們有沒有把產品「做對」？	拿目前做出來的東西，去跟規格書與需求清單 (specifications and requirements) 進行比對檢查。	確保寫出來的程式碼與架構，完全符合當初設計文件與 SRTM 的規定。
確認 (Validation)	我們有沒有做出一套「對的產品」？	拿做出來的最終成品，放到真實世界中，去檢驗它是否能滿足使用者真正的需求與期望 (user's actual needs)。	確保這套軟體在現實環境中，真的能解決客戶的商業痛點與資安問題。

驗證 (Verification) 與確認 (Validation) 的安檢工作，必須交由一個「與原本開發團隊完全獨立、毫無瓜葛的第三方」來負責執行。